one thought here - should we remove the autogenerate logic for the s2 keys since we are not ready to use them yet? we can keep most of the logic in place for when we are ready to generate them and it still allows users to switch between zwavejs2mqtt and zwave-js with S2 devices if they need to. It's also possible that users may not notice these new configuration options immediately and would want to generate keys on their own rather than trusting the addon (that's what I would want to do)

Are the S2 keys somehow stored in the controller device or other devices even if no devices are included with S2? Ie, does it matter if the user changes these keys later before starting to include devices using S2?

If the keys can be changed without consequences by the user before starting to include devices with S2, I don't think it matters if we auto-generate keys now.

Are the S2 keys somehow stored in the controller device or other devices even if no devices are included with S2? Ie, does it matter if the user changes these keys later before starting to include devices using S2?

If the keys can be changed without consequences by the user before starting to include devices with S2, I don't think it matters if we auto-generate keys now.

No and fair point

is there anything holding this PR back from being merged?

This looks ok, but I'd like someone that is familiar with bashio to approve before merge.

We need to support the new keys in the integration add-on management too. I'll work on that tonight.

Here's the core PR to manage S2 keys also in the integration.
home-assistant/core#56783

It can be merged after we merge here and bump the client library used in the core (#2188).

Hmm, I'm getting this error when testing the add-on locally.

Error: Invalid networkKey defined

I fixed the error. It was just a typo in the config template.

Tested and working! 🎉